데이터 모델

모델링

• 현실세계를 추상화, 단순화, 명확화하기 위해 일정한 표기법에 의해 표현하는 기법이다.
• 세 가지 관점: 데이터 관점Data, What + 프로세스 관점Process, How + 상관 관점Data vs. Process

데이터 모델링

• 정보시스템을 구축하기 위한 데이터 관점의 업무 분석 기법
• 현실세계의 데이터에 대해 약속된 표기법에 의해 표현하는 과정
• 데이터베이스를 구축하기 위한 분석/설계의 과정
• 모델링시 유의점: 중복(Duplication), 비유연성(Inflexibility), 비일관성(Inconsistency)
• 모델링의 단계: 개념적 데이터 모델링 $\rightarrow$ 논리적 데이터 모델링 $\rightarrow$ 물리적 데이터 모델링
  • 대부분의 프로젝트에서는 개념적 데이터 모델링과 논리적 데이터 모델을 함께 수행한다.

데이터 모델링의 세 가지 요소

• Things 업무가 관여하는 어떤 것 = 엔터티(Entity)
• Attributes 어떤 것의 성격
• Relationships 업무가 관여하는 어떤 것 간의 관계

데이터 모델 표기법

• Chen: 대학 교재에서 가장 많이 이용하는 표기법
• IDEF1X: 마름모와 원을 이용한 표기법
• IE/Crow's Foot: 까마귀발 모양의 표기법으로 가장 많이 사용한다.
• Min-Max/ISO: 기수성을 더 정교하게 표현한 표기법
• UML: 스테레오타입을 이용하여 엔터티 표현

엔터티(Entity)

엔터티(Entity)란 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적/영속적인 것(Things)이다. 엔터티는 그 집합에 속하는 개체들의 특성을 설명할 수 있는 속성(Attributes)을 갖는다. 또한, 엔터티는 인스턴스의 집합이라 말할 수 있고, 반대로 인스턴스는 엔터티의 하나의 값에 해당한다.

엔터티의 명명

• 현업 업무에서 사용하는 용어를 사용한다.
• 가능하면 약어를 사용하지 않는다.
• 단수명사를 사용한다.
• 모든 엔터티에서 유일하게 이름이 부여되어야 한다.
• 엔터티 생성의미대로 이름을 부여한다.
  • e.g. 고객이 어떤 제품들에 대해 주문하여 발생하는 행위엔터티 $\rightarrow$ 주문목록(O) vs. 고객제품(X)
  • 고객제품으로 생성시 고객이 주문한 제품인지, 고객의 제품인지 의미가 모호하다.

엔터티의 발생시점에 따른 유형

엔터티의 특징

• 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.
• 유일한 식별자에 의해 식별이 가능해야 한다.
• 영속적으로 존재하는 인스턴스의 집합이어야 한다. (두 개 이상)
• 엔터티는 업무프로세스에 의해 이용되어야 한다.
• 엔터티는 반드시 속성이 있어야 한다.
• 엔터티는 다른 엔터티와 최소 한 개 이상의 관계가 있어야 한다. (단, 통계성이나 코드성 엔터티의 경우 관계 생략 가능)

속성(Attribute)

속성이란 업무에서 필요로 하는 엔터티에서 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위이다. 데이터 모델에서 가장 작은 단위이기 때문에 이러한 특성을 속성의 원자성이라고 한다.

속성의 분류

• 파생속성을 정의한 경우, 속성정의서에 업무로직을 기술하여 데이터의 정합성이 유지될 수 있도록 해야한다.

속성의 명명

• 해당 업무에서 사용하는 이름을 부여한다.
• 서술식 속성명은 사용하지 않는다.
• 약어사용은 가급적 제한한다.
• 전체 데이터모델에서 유일성을 확보하는 것이 좋다.

도메인

각 속성이 가질 수 있는 값의 범위로, 엔터티 내에서 데이터 타입과 크기 그리고 제약사항을 지정하는 것이다. 각 속성은 도메인 의외의 값을 갖지 못한다.

• 학점 속성의 도메인: 0.0 ~ 4.5 사이의 실수 값
• 주소 속성의 도메인: 길이가 30자리 이내인 문자열

관계(Relationship)

하나 또는 두 개의 엔터티로부터 인스턴스를 연관시키기 위한 업무적인 이유를 의미한다. 둘 사이를 표현할 때 동사로 표현되는 영역이 엔터티와 엔터티의 관계로서 기술될 수 있다.

ERD vs. 클래스 다이어그램

ERD에서는 존재적 관계와 행위에 의한 관계를 구분하지 않고 표현하는 반면 클래스다이어그램에서는 이를 구분하여 연관관계와 의존관계로 표현하고 있다.

• 연관관계: 항상 이용하는 관계로 존재적 관계에 해당 (실선 →)
  • e.g. 부서와 사원 엔터티 간의 소속 관계
• 의존관계: 상대방 클래스의 행위에 의해 관계가 형성될 때 해당 (점선 ⇢)
  • e.g. 주문과 배송 엔터티 간의 배송근거 관계

관계명(Membership)

참여자의 관점에 따라 관계이름이 능동적이거나 수동적으로 명명된다. 명명규칙은 아래와 같다.

• 구체적이지 않은 애매한 동사는 피한다
  • e.g. 관련이 있다(X), 관계된다(X)
• 현재형으로 표현한다.
  • e.g. 수강 신청한다(O) vs. 수강을 신청했다(X), 강의를 할 것이다(X)

관계차수(Degree/Cardinality)

Crow’s Foot 모델에서는 한 개가 참여하는 경우는 실선을 그대로 유지, 다수가 참여한 경우는 까마귀발과 같은 모양으로 그려준다. M:N관계로 표현된 데이터 모델은 이후에 두 개의 주식별자를 상속받은 관계엔터티를 이용하여 세 개의 엔터티로 구분하여 표현한다.

• 1:1 = ONE TO ONE
• 1:N = ONE TO MANY
• M:N = MANY TO MANY

관계선택사양(Optionality)

• 선택관계: ERD에서 선택참여하는 엔터티쪽을 원으로 표시한다.
• 필수관계: 아무런 표시를 하지 않는다.

관계 체크사항

• 두 개의 엔터티 사이에 관심있는 연관규칙이 존재하는가?
• 두 개의 엔터티 사이에 정보의 조합이 발생하는가?
• 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
• 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 있는가?

식별자(Identifier)

하나의 엔터티에 구성되어 있는 여러 개의 속성 중에 엔터티를 대표할 수 있는 속성을 의미한다. 하나의 엔터티는 반드시 하나의 유일한 식별자가 존재해야 한다.

식별자의 특징

• 유일성: 주식별자에 의해 엔터티 내의 모든 인스턴스들을 유일하게 구분한다.
• 최소성: 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다.
• 불변성: 주식별자가 한번 특정 엔터티에 지정되면 그 식별자의 값은 변하지 않아야 한다.
• 존재성: 주식별자가 지정되면 반드시 데이터 값이 존재한다. (NULL 불허)

식별자의 분류

식별자관계(Identifying Relationship)

• 자식엔터티의 주식별자로 부모의 주식별자가 상속이 되는 경우를 식별자관계라고 한다.
• 식별자관계로만 설정시 문제점
  • 부모에서 자식으로 식별자관계로 연결되므로 자식엔터티의 주식별자의 속성 수가 많아지게 된다.
  • 엔터티 조인을 위한 SQL구문의 WHERE절이 길어져 개발복잡성과 오류가능성을 유발할 수 있다.

-- [TABLE LIST] --
-- PLANT(1)       to   EQUIPMENT(N)
-- EQUIPMENT(1)   to   EQPSTS (N)
-- EQPSTS(1)      to   EQPEVSTS(N)
-- EQPEVSTS(1)    to   EQPEVSTSHST(N)
-- EQPEVSTSHST(1) to   EQP_ITEM(N)
-- EQPEVSTSHST(1) to   EQP_WORKER(N)

-- [PK INFO] --
-- EQPEVSTSHST's PK: PLANT, EQUIP_ID, STATUS_SEQ, EVENT_ID, TRANS_TIME
-- EQP_ITEM's PK: PLANT, EQUIP_ID, STATUS_SEQ, EVENT_ID, TRANS_TIME, ITEM_CD
-- EQP_WORKER's PK: PLANT, EQUIP_ID, STATUS_SEQ, EVENT_ID, TRANS_TIME, WORKER_SID

SELECT A.*, B.ITEM_CD, C.WORKER_SID
  FROM EQPEVSTSHST A, EQP_ITEM B, EQP_WORKER C
 WHERE 1=1
   -- INNER JOIN CONDITIONS A,B + ITEM_CD
   AND A.PLANT = B.PLANT           AND A.EQUIP_ID = B.EQUIP_ID
   AND A.STATUS_SEQ = B.STATSU_SEQ AND A.EVENT_ID = B.EVENT_ID
   AND A.TRANS_TIME = B.TRANS_TIME AND B.ITEM_CD = 'A001'
   -- INNER JOIN CONDITIONS A,C + WORKER_SID
   AND A.PLANT = C.PLANT           AND A.EQUIP_ID = C.EQUIP_ID
   AND A.STATUS_SEQ = C.STATSU_SEQ AND A.EVENT_ID = C.EVENT_ID
   AND A.TRANS_TIME = C.TRANS_TIME AND C.WORKER_SID = 'A012008001'

비식별자관계(Non-Identifying Relationship)

부모엔터티로부터 속성을 받았지만 자식엔터티의 주식별자로 사용하지 않고 일반속성으로만 사용하는 경우를 비식별자관계라고 한다.

• 비식별자관계에 의한 외부속성 생성
  • 부모 없는 자식이 생성될 수 있는 경우
  • 엔터티별로 데이터의 생명주기를 다르게 관리할 경우
  • 여러 엔터티가 하나의 엔터티로 통합되어 표현되었는데, 각각의 엔터티가 별도의 관계를 가질 때
  • 상속받은 주식별자를 사용해도 되지만 자식엔터티에서 별도의 주식별자를 생성하는 것이 더 유리할 경우
• 비식별자관계로만 설정시 문제점
  • 비식별자관계로 설정시 기준속성(사원번호, 거래번호 등)들이 자식엔터티로 상속되지 않는 경우, 부모엔터티와의 불필요한 조인이 다량으로 유발되면서 SQL구문도 길어지고 성능이 저하되는 현상이 발생된다.

-- [TABLE LIST] --
-- REP001T(1)    to   REP005T(N)
-- REP005T(1)    to   REP007T(N)

-- [PK INFO]: 비식별자관계 가정 --
-- REP001T(1)'s PK: 점검번호(PK)
-- REP005T(1)'s PK: 분야번호(PK)
-- REP007T(1)'s PK: 점검항목코드(PK1), 세부점검항목코드(PK2)

-- 비식별자관계 --
SELECT A.점검번호, C.*
  FROM REP001T A, REP005T B, REP007T C
 WHERE A.점검번호 = B.점검번호 AND B.분야번호 = C.분야번호 AND A.점검번호 = '301'

-- 식별자관계 --
SELECT C.점검번호, C.*
  FROM REP007T C
 WHERE C.점검번호 = '301'

식별자관계와 비식별자관계 비교

식별자관계와 비식별자관계의 결정

자식엔터티에서 부모엔터티로부터 받은 외부식별자를 자신의 주식별자로 이용할지 또는 부모와 연결이 되는 속성으로만 이용할 것인지를 결정해야 한다. 기본적으로 식별자관계로 모든 관계가 연결되면서 다음 조건에 해당할 경우 비식별자관계로 조정하면 된다.

/* 비식별자관계 선택 프로세스 */
if (관계의 강/약분석 == "약한관계") {비식별자관계 설정 고려;}
else if (자식테이블독립PK필요 == "YES") {비식별자관계 설정 고려;}
else if (SQL복잡도증가 & 개발생산성저하 == "YES") {비식별자관계 설정 고려;}
else {식별자관계 설정;}